Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000008_owner-urn-ietf _Tue Oct 8 03:59:51 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA29158 for urn-ietf-out; Tue, 8 Oct 1996 03:59:51 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA29153 for <[e-mail]>; Tue, 8 Oct 1996 03:59:43 -0400
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA12430  (mail destined for [e-mail]); Tue, 8 Oct 96 03:59:41 -0400
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16670(5)>; Tue, 8 Oct 1996 00:59:39 PDT
Received: by golden.parc.xerox.com id <2768>; Tue, 8 Oct 1996 00:59:24 PDT
To: [e-mail]
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]> (message
    from Patrik Faltstrom on Mon, 7 Oct 1996 21:30:40 PDT)
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[e-mail]>
Message-Id: <96Oct8.005924pdt."2768"@golden.parc.xerox.com>
Date: Tue, 8 Oct 1996 00:59:24 PDT
Sender: [e-mail]
Precedence: bulk
Reply-To: Larry Masinter <[e-mail]>
Errors-To: [e-mail]

This sounds a bit more like a diatribe than I'd like.... I started out
trying to get some explicit description of the advantages of NAPTR
over what seems like a far simpler method (PURLs).

> The A record does not have a priority. MX-records do have that,
> A records does not. You can not change the spec of A-records.

Tell me again why replicated services need to have 'a priority'.
What requirements does it help satisfy?

> This is just how things are implemented, especially when one
> start using things that is not really DNS (NIS for example).
> To be able to get around this problem -- we need a new resource
> record type.

Are you saying that you'd expect NIS to work with NAPTR but not to
work with long A records? I vaguely remember a patch several years ago
to the Sun NIS implementation to fix the problem with a server
(merit.edu?) that had more A records than before. I think that to get
around a bug in implementations of DNS, you need to fix the bug.

>> I don't understand why www.purl.org must have a shorter lifetime than
>> any NAPTR name. You just vow to not reassign the name. If you can't do
>> that with ".org", then pick a new top level domain.

> Because the NAPTR record is the second abstraction level you really
> need to be able to handle renaming of resources on the net.

I've stared at this, but it seems like you're saying that "you need it
because you really need it". Why do you need a second abstraction
level to be able to handle renaming of resources on the net? PURLs
handle renaming of resources by letting you go to the PURL server and
tell the PURL server where the resource is now.
    PURL -> URL -> resource
If the resource gets renamed, you change the PURL -> URL mapping. No
second level abstraction needed.

> You also can handle other protocols than HTTP which makes the NAPTR
> proposal (NAPTR records together with SRV records) much more long
> lived.

The NAPTR proposal has a single protocol for finding an appropriate
resolution service. The NAPTR protocol suggests that looking up
    urn:duns:002372413:annual-report-1997

means a DNS NAPTR lookup on duns.urn.net, examining the syntax for
tokens N2L/N2C/N2R, followed by another DNS lookup for the SRV record.

This protocol uses DNS, but it is still a protocol. It has a syntax,
the syntax must be parsed, the syntax has no version information, the
syntax is not in itself widely implemented, might need to be changed,
etc.

The PURL system also has a single protocol for finding an appropriate
resolution service. That protocol consists of doing a DNS A record
lookup on duns.resolver.purl.org, then picking one of the IP addresses
you get, and doing a HTTP request.

While HTTP might not be 'long-lived', are you claiming that this
design of NAPTR is longer-lived, or should be? How long? On what
grounds to you evaluate longevity of protocols? There is "N2L", "N2C"
and "N2R", will there not be another kind of category of "N2X" for 20
years?

>> The DNS entries for resolver.purl.org already give you all the
>> indirection you need. Why add more?

> No, it does not give the information about priority and
> protocol that is needed. We should not at all of the meetings
> we had last year still be talking about NAPTR records which
> forces everyone to change their resolvers if it was not needed.

On 'priority', you haven't actually said why you need priority. In
this paragraph you assert that you had a meeting where everyone agreed
that priority was needed, but it's not apparent why URN resolution
needs priority. That you talked about NAPTR records and decided you
needed priority then still doesn't explain WHY you thought you needed
it. I'm just asking you to write down what the advantage actually is.
I understand and I'm willing to trust that there advantages, but you
should say.

To reiterate a bit on the 'protocol' issue: it's always possible to
delegate to some other protocol in a 303 Location: response; at least,
though, if you force people to register "dunslink" and "rcds" as new
URL schemes, we'll have a mechanism for dealing with those tokens in a
standards-track way. As you've specified it, there's no change-control
on what those tokens might mean: if there are two versions of
rcds, should NAPTR records upgrade all their records when the resolver
upgrades from rcds1 to rcds2? If there's a version skew between the
client rcds and the server rcds such that the server rcds can't
respond to the client's ancient rcds implementation, should the
rejection influence the handling of priorities?

> The PURL methods do work for locating HTTP servers, IF you
> name your resources exactly the way you point it out Larry,
> i.e. that you do have a special namespace allocated for the
> PURL names which does not have anything in common with the
> hostname namespace.

a) Are you claiming that PURL is limited to "locating HTTP servers"?
The PURL method could work for locating any resource that can be
located by a URL. The PURL method happens to use HTTP to do the
location. However, if you have a report stored in a z39.50 server with
URL

     z3950r://isite.bogus.com/0123@ab125212312xx0A
and you refer to it with
     urn:duns:002372413:annual-report-1997

you can still use PURLs to do it, by looking up
    http://duns.resolver.purl.org/002372413:annual-report-1997

and getting back a
    303
    Location: z3950r://isite.bogus.com/0123@ab125212312xx0A

b) "IF you name your resources exactly the way you point it out"

This is the rub: PURLs don't have regular expression matching.
And the DNS caching allows caching of patterns.

> When coming to this conclusion, we did also think about the
> need for different resolution protocols (to handle the case
> when someone is running a resolution service for a publisher,
> and who is responsible for what in the resolution process)

The purl system is potentially recursive. You could redirect from one
URL to another. So it allows multiple roles or a single one. NAPTR
however seems to have only two roles: you either own the DNS entry and
manipulate that, or else you own the resolver. That's an advantage, I
suppose, but it seems less flexible.

There's a performance issue, in that DNS records cache better,
although TTL seems as risky as max-age in HTTP.

Maybe one way to improve PURLs would be to have the 'redirect' message
in HTTP allow pattern-redirects.

Regards,

Larry